[pull] main from fern-api:main - #905

#17457)

* fix(cli-generator): make credential temp-file writes unique per writer

`atomic_write` derived its temp file name from the target alone, so every
concurrent writer used the same sibling path (`auth-keyring.tmp`). Whichever
process renamed first moved it away and the rest failed with

  error[auth]: Failed to rename .../auth-keyring.tmp: No such file or directory

The temp name now carries the writer's pid plus a process-local counter. The
pid covers the case that actually bit us — separate CLI processes — and the
counter covers two writers inside one process, which is also what makes the
behavior testable without spawning subprocesses.

Found via a generated wire-test suite on a ~680-case workspace: the harness
seeds a token with `auth login --with-token` per authenticated case, cargo runs
those in parallel, and a different subset of cases died on each run. Two runs of
the identical commit failed with 1 and then 2 casualties respectively, which is
what ruled out a deterministic break. Small seed fixtures have too little
concurrency to reach it, so it surfaced on a real workspace before ours.

`rename` was already atomic for readers, so no partially written credential
file was ever observable — only writer-vs-writer collisions on the temp path.
`FileKeyringStore::set` remains an unlocked read-modify-write of the whole map,
so simultaneous writers can still clobber one another's entries; that needs
file locking and is deliberately left alone.

The new test fails against the old derivation with the exact production error
(15 of 16 writers), so it pins the behavior rather than merely exercising it.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix(cli-generator): unlink credential temp files on failed writes

Unique-per-writer temp names removed the self-limiting property of the old
shared `auth-keyring.tmp`: a failed write used to leave one stale file that the
next write reused, whereas unique names leak a distinct credential-bearing file
per failure in a directory nothing prunes. `TempFileGuard` unlinks on drop,
covering every early return and unwinding panic between `write` and `rename`
(a SIGKILL still leaks — no in-process guard can cover that).

Also switches the temp-name counter from `AtomicU64` to `AtomicUsize`, which is
available on targets lacking 64-bit atomics, and records the `$XDG_CONFIG_HOME`
root cause in the changelog: the wire harness sets a per-case `HOME`, but
`config_dir()` reads `$XDG_CONFIG_HOME` first on Linux, so CI runners funneled
every authenticated case into one shared credential store.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix(cli-generator): reattach atomic_write docs to the function

`TempFileGuard` was inserted between `atomic_write`'s doc comment and the
function, so rustdoc attached the whole rationale to the guard struct and left
`atomic_write` undocumented. It compiles either way, which is why nothing
flagged it. Guard now precedes the doc block, and the doc block notes that the
guard is what keeps unique temp names from accumulating as orphans.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>